The protocol used for connecting between the exporter and the engine-exciter (also known as exgine) in a radio station, is known as the exporter to exgine protocol E2X, as defined by IBIQUITY DIGITAL CORPORATION7. This protocol performs two main functions. The first function is the transmission of HD RadioJ (High Definition) data, from the exporter at the studio to the exgine at the transmitter. The second function is the synchronisation of the exporter with the exgine.
FIG. 1 illustrates a basic overview the third generation IBOCJ radio broadcast system architecture. This architecture differs from previous generations in that most of the IBOCJ functions and equipment are moved from the transmitter site to the studio site.
The only function in the IBOCJ system that remains at the transmitter site is the digital IBOCJ modulation performed inside the exciter engine (Exgine) modulator board. Keeping the modulation function at the transmitter site is necessary because the digital bit stream to be modulated can be transferred in fewer than 150 kbps. IBOCJ modulation turns this bit stream into a discrete time signal that requires the equivalent of 23 Mbps to be transferred across an STL. Though required to contain the complete FM baseband frequency spectrum, it is inefficient to carry this amount of information across RF based STLs.
The transmitter site receives two data feeds from the studio: an audio feed for traditional FM broadcast, which may be carried in any digital or analog industry standard, and an Ethernet based digital data stream for IBOCJ modulation. This digital data stream is not limited to carrying audio data and may contain program service data or other data services along with one or more additional compressed audio streams.
The major IBOCJ system components at the studio site are the Exporter, Importer and system synchronization unit. The Exporter=s responsibilities include delaying the analog audio to match the digital on-air delay and passing the audio signal to the STL. On the digital side, the Exporter performs the audio coding of the digital main program and multiplexing all digital content including program service data for the main program, as well as, all digital content originating from the Importer.
The Importer can capture two additional audio feeds for secondary program services which are encoded in the Importer and are passed to the Exporter along with their corresponding program service data.
The broadcast architecture is synchronous in nature in that a discrete number of audio samples captured at the studio translates into a discrete number of digital symbols produced at the exciter. The synchronization unit synchronizes the incoming audio feed to a GPS based timing reference, which in turn affects the timing of all operations in the system.
The STL link must be able to carry Ethernet/IP based traffic along with traditional audio streams, requiring a digital STL. Many stations have transitioned to digital STLs in favor of a digital audio feed over an analog feed for improved audio quality. Most STL vendors now provide upgrade paths to share the existing digital STL bandwidth between audio paths and Ethernet based paths. However, since most STLs have traditionally been unidirectional in nature, many STLs today also only provide a unidirectional Ethernet path. Even basic network functions, such as the address resolution protocol, often require a bidirectional data path between a sender and receiver on a network. It is important that the digital data stream protocol does not require a bidirectional data path, but it may make use of a bidirectional link if one is present.
Classifying the bandwidth requirements of the data portion of the digital data stream is relatively straight forward and iBiquity Digital CorporationJ has sufficiently detailed these requirements. The bandwidth requirements for the synchronization stream, on the other hand, are more difficult to determine.
The E2X may employ the TCP/IP mode for bidirectional STL (Studio to Transmitter link). The TCP/IP mode addresses intermittent packet loss through data retransmission, but requires an additional 40% of the STL bandwidth for overhead and control data, which is undesirable in bandwidth limited links. In addition to this disadvantage, the TCP/IP mode does not allow for point-to-multipoint communication, which requires a separate exporter at the studio for each exgine at the transmitter. Furthermore, TCP windowing provides flow control, which results in a delayed data delivery and possible disconnection. However, since data packets are only useful if they are received prior to when they are scheduled to be transmitted delayed data will be discarded if it is received after it is scheduled to be broadcasted on air. Moreover, the loss of the TCP/IP connection requires re-connection, which translates into an extended outage of data streaming.
The E2X synchronization scheme places stringent STL throughput requirements on the link. In order to pass a data packet of 19330 bytes (MP3) within 92.8 ms, a dedicated bandwidth of at least 1.59 Mbps is needed, not withstanding additional packet overhead. The latter makes exgine synchronization dependent on packet throughput delays and compression efficiency, service modes, additional traffic, and link throughput bit rate changes. Clock packets no longer are a measure of throughput delay for any link that cannot guarantee the above bandwidth. On a 256 kbps link, this packet takes in excess of 600 ms to be transferred. As illustrated in FIG. 2, the instantaneous bit rate required by E2X causes the STL to periodically enter a congestion state, making the link very unresponsive to other traffic on the link, and inflicts a cyclically patterned error on the E2X synchronisation stream, which leads to an incorrect measure of link throughput delay. The heavy filtering exhibited by the synchronisation stream does not remove this error. While TCP/IP addresses intermittent bit errors and packet loss, its retransmission scheme does not consider the synchronization stream potentially exacerbating the congestion problem.
Accordingly, since the TCP/IP mode is designed for data transfer, and guaranteed delivery of data on the expense of the speed, the TCP/IP cannot be relied upon for real time streaming. The alternative is the User Datagram Protocol (UDP) mode which lends itself to unidirectional real time streaming of data. The UDP is connectionless, and allows for point-to-multipoint communication using broadcast or multicast mode on a unidirectional link.
However, to provide an overall sufficient quality of service, the standard UDP mode requires an extremely reliable network with a Bit Error Rate of almost zero, because UDP does not guarantee any data delivery and the application using UDP must tolerate the loss of data. In the case of HDJ data transmission, the loss of a single packet translates into a 1 to 2 seconds of HDJ outage. For instance, if the end-user quality of service (QoS) is intended to be 99.999% then the average packet loss should be 1 in 1.6 millions which translates into a 1 to 2 seconds outage in every 41.1 hours of broadcasting. If the QoS drops to 99.99% the average packet loss will be 1 in every 160,000 packets. If it drops further to 99.2%, the average packet loss is 1 in every 2000 packets, and so on.
Several attempts have been made in the past to address the problem of providing data to multiple users in bandwidth limited networks. For instance, International Patent Application No. 050,320,26 (Fuchs et al.) describes a method for multi-casting data to a plurality of users. The method includes the steps of transmitting a notification on an upcoming multicast transmission to a plurality of receivers designated to receive the multicast transmission; tuning by at least one of the plurality of receivers to one or more multicast channels responsive to the notification; transmitting a data file from a data server on the one or more multicast channels without receiving acknowledgments from the receivers at the server as to whether they received the notification or not; determining receivers designated to receive the multicast transmission that did not receive at least a portion of the data file; and attempting to deliver the data file to the determined receivers.
United States Patent Application Publication No. 2006/0206618 (Zimmer et al.) describes a method and an apparatus for providing remote audio using an out-of-band (OOB) communication channel. The method enables audio content to be broadcasted from a media host to multiple media clients using an OOB communication channel that is transparent to operating systems running on the media host and clients. Audio content can be read from a CD-ROM, DVD, or hard disk drive, at the media host. The audio data is packetized using an OOB networking stack and transferred to the media clients, whereupon the packets are processed by a client-side OOB networking stack. The audio data is then extracted from the packets and provided to an audio sub-system to be rendered. In one embodiment, the apparatus comprises an input/output controller hub (ICH) including an embedded High Definition audio sub-system and a separate LAN micro-controller.
Canadian Patent No. 2,299,141 (Yue et al.) describes a method for use in a packet server. The method includes the steps of formatting the data packets in accordance with Lightweight. IP Encapsulation using IP/UDP transport. The packet encapsulated in this format includes a UDP header field and at least one multiplexing header and an associated multimedia data packet. The multiplexing header comprises a user identifier field, a length indicator field, and a Amore@ field used to indicate the use of more than one multiplexing header and associated multimedia data packet for transporting incoming data packets.
United States Patent Application Publication No. 2003/0086442 (Reynolds et al.) describes a method for recovering clock signals including generating a media sync signal to synchronize processing of digital media, and generating a transmission reference clock signal to define a duration of a transaction through a packet-based data network. The media sync is sent to a slave node of the network. The media sync and transmission clock signals are correlated to generate phase correlation information, and the phase correlation information is also sent to the slave node.
United States Patent Application Publication No. 2006/209941(Kroeger) describes a method for synchronizing an exciter clock with a modem frame clock in a broadcasting system. The method includes the steps of receiving a plurality of modem frame pulses that are representative of the start of modem frames of audio signals and data signals, wherein timing of the modem frame pulses is controlled by a modem frame clock; producing an exciter clock signal; counting pulses representative of the exciter clock signal to produce a count representative of timing error of each incoming modem frame pulse, and controlling the exciter clock signal in response to the count.
International Patent Application No. 2005/034414 (Compton et al.) describes a method of synchronizing the phase of a local image synchronisation signal generator of a local video data processor in communication with an asynchronous switched packet network to the phase of a reference image synchronisation signal generator of a reference video data processor also coupled to the network. The local and reference processors have respective clocks, and the reference and local image synchronisation signal generators generate periodic image synchronisation signals in synchronism with the reference and local clocks, respectively.